Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SNOW-1814204 Use fair lock to ensure granting sequence #911

Merged
merged 2 commits into from
Nov 21, 2024

Conversation

sfc-gh-ggeng
Copy link
Contributor

We should make sure that the long waiting thread get the lock. Otherwise, client’s later insertRow request with later offset token may come and get the lock first -- it will get the earlier internal continuation token and insert first. This could cause issues when incident happens and customer trying to replay the data. This may also cause the data ingested not in sequence.

We should use the fair synch lock to make sure that the thread with the longest waiting time (come earlier) wins and get the lock. Doc for the ReentrantLock: https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/ReentrantLock.html

@sfc-gh-ggeng sfc-gh-ggeng requested review from sfc-gh-tzhang and a team as code owners November 19, 2024 01:09
Copy link
Contributor

@sfc-gh-tzhang sfc-gh-tzhang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, let's make sure the perf implication for normal use cases is minimal

@@ -357,7 +357,7 @@ public InsertValidationResponse insertRows(
this.channelState = channelRuntimeState;
this.channelFullyQualifiedName = fullyQualifiedChannelName;
this.nonNullableFieldNames = new HashSet<>();
this.flushLock = new ReentrantLock();
this.flushLock = new ReentrantLock(true);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any perf implication with this change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There could be perf implication main when we are doing the expected things.
When the customer have threads waiting for the lock and a new thread comes to acquire the lock, for unfairness lock, we would directly give the lock to the new thread; while for fairness lock, we would need to wait for the first come thread to wake up -- meaning that the performance implication happens when we are not inserting the data according to the customer's order.

@sfc-gh-ggeng sfc-gh-ggeng enabled auto-merge (squash) November 21, 2024 21:56
@sfc-gh-ggeng sfc-gh-ggeng merged commit 59ce9e0 into master Nov 21, 2024
51 checks passed
@sfc-gh-ggeng sfc-gh-ggeng deleted the ggeng_SNOW-1814204-lock branch November 21, 2024 23:10
@sfc-gh-hmadan
Copy link
Collaborator

Please add a test to verify this behavior never regresses?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants